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Beschreibung 

Verfahren zur Verbindung von Stackmanipulationsangrif f en bei 
Funktionsauf ruf en 

5 

Auf zukunftigen Chipkarten sollen voneinander abhangige Soft- 
waremodule verschiedener Hersteller installiert werden. Un- 
terschiedliche Module unterschiedlicher Hersteller haben da- 
bei unterschiedliche Zugrif f srechte auf Ressourcen der Chip- 
0 karte. Beispielsweise hat nur das Betriebssystem Zugriff auf 
bestiimnte Speicherbereiche im NVRAM, die von anderen Modulen 
nicht manipuliert werden diirfen. 

Eine solche Zugrif fsbeschrankung zum Schutz der Arbeitsspei- 
5 cherbereiche einzelner Programme vor veranderndem Zugriff 

durch andere auf der Chipkarte ablaufende Programme, ist bei- 
spielsweise in dem U.S. -Patent 5,754,726 beschrieben. Das 
dort beschriebene Verfahren stellt zwar sicher, dafi von einem 
auf der Chipkarte aktiven Programm keine Arbeitsspeicherbe- 
0 reiche anderer Programme manipuliert werden konnen. Eine wei- 
tere Angrif f smoglichkeit besteht jedoch darin, nicht den Ar- 
beitsspeicher , sondern den Stapelspeicher mit den jeweiligen 
Rucksprungadressen der Unterprogramme zu verandern. Ein sol- 
cher Manipulationsangrif f auf den Stapelspeicher (Stack) des 
5 Prozessors, kann mit dem Verfahren der U.S. -PS 5,754,762 
nicht abgewehrt werden. 

Aus Speicheref f izienz- und Perf ormancegriinden liegen die 
Stacks von aufgerufener und aufrufender Funktion namlich phy- 

0 sikalisch im selben Speicherbereich hintereinander . Da kon- 
zeptionell nicht ausgeschlossen werden kann, daft eine Biblio- 
theksf unktion auf hohem Sicherheitsniveau eine Funktion einer 
Applikation mit niedrigem Sicherheitsniveau aufruft, besteht 
ein mogliches Angrif fsszenario darin, daft die aufgerufene 

5 Funktion der Applikation durch Zugriff auf den Programmstack 
den Datenbereich der Bibliotheksf unktion auf dem Stack mani- 
puliert . 
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Auf Chipcard Controllern ist eine Losung im Stand der Technik 
bisher nicht vorhanden. Die Problemstellung ist neu, da bis- 
her ein Hersteller fur die gesamte Software zustandig war. 

In modernen Prozessoren wird z.B. eine Page Table oder Seg- 
ment Decriptor Table (MMU) verwendet, in die das Multitas- 
king-Betriebssystem den fur die Applikation gultigen Spei- 
cherbereich eintragt. Die ProzefSkommunikation und -uberwa- 
chung wird dabei vom Betriebssystem durchgef uhrt . 

Funktionsauf ruf e zwischen Funktionen auf unterschiedlichen 
Sicherheitsniveaus gehen bei Chipkarten aus Perf ormancegrun- 
den nicht iiber das Betriebssystem, sondern werden direkt aus- 
gefuhrt. 

Es ist daher Aufgabe der Erfindung, die direkte und indirekte 
Manipulation des Stack-Speicherbereichs als sicher bewerteter 
Funktionen durch als unsicher bewertete Funktionen zu verhin- 
dern . 

Erf indungsgemali wird diese Aufgabe durch ein Verfahren ge- 
lost, bei dem der Stackzugriff bei einem Aufruf einer unsi- 
cheren Funktion durch Hardware auf deren Stackbereich be- 
schrankt wird. 

Es ist dabei besonders bevorzugt, zur Beschrankung des Stack- 
zugriffs vor dem Aufruf der unsicheren Funktion die Referenz 
auf den Stackframe der aufrufenden Funktion zu speichern. 
Weiter ist es dabei bevorzugt, einen Mechanismus vorzusehen, 
durch den verhindert wird, dafi die aufgerufene Funktion den 
Wert der Referenz auf den Stackframe verandern kann. Weiter 
ist es bevorzugt, durch einen Schut zmechanismus sicherzustel- 
len, daft der Stackpointer nicht den gultigen Stackbereich der 
aktuellen Funktion iiberschreitet . 
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Besonders bevorzugt ist es, bei dem Rucksprung aus der unsi- 
cheren Funktion den urspriinglichen Zustand auf den Stack wie- 
derherzustellen . 

5 Das erf indungsgemali gunstigste Verfahren lauft so ab, daft 
beim Funktionsauf ruf zunachst auf dem Stack ein Speicherbe- 
reich fiir zu schiitzende Funktionsdaten reserviert und optio- 
nal die Funktionsargumente dahinter auf den Stack gelegt wer- 
den und die im geschutzten Bereich liegende Referenz auf den 
10 Stackframe der aufrufenden Funktion auf den zuvor reservier- 
ten Bereich des Stacks gelegt und die Referenz auf den Stack- 
frame der aufgerufenen Funktion in den geschutzten Bereich 
geschrieben wird. 

15 Im folgenden wird die Erfindung anhand des in den beigefugten 
Zeichnungen dargestellten Ausfuhrungsbeispiels naher erlau- 
tert. Es zeigen: 

Fig. 1 die Belegung des Stacks und der zugehorigen Register 
20 vor und nach dem Funktionsauf ruf ; und 

Fig. 2 schematisch den Ablauf der Aufrufe bei einem abgesi- 
cherten Funktionsauf ruf - 

'^'^l^'^25 Bisher lieferte ein einziger Chipkartenhersteller sowohl das 
Betriebssystem der Chipkarte als auch die Anwendungsprogram- 
me. Das Betriebssystem der Chipkarte konnte also als ein Teil 
des Anwendungsprogramms gesehen werden. Das Chipkartenbe- 
triebssystem und die Anwendungsprogramme wurden auf speziell 
30 hergestellten Masken fiir das ROM (Nurlesespeicher ) der Chip- 
karten-IC's geliefert. Es handelte sich also bisher um Losun- 
gen, bei denen die Programme im wesentlichen hardwaremaftig, 
also fest verdrahtet, vorgegeben waren. 



35 



Die vorliegende Erfindung behandelt demgegeniiber eine Situa- 
tion, bei der verschiedene Hersteller Bibliotheken und Anwen- 
dungsprogramme liefern konnen, die dann auf einer Karte ko- 
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existieren mussen. Aus Sicherheitsgriinden hat die Programmar- 
chitektur der Chipkarte dann zu ermoglichen, das Betriebssy- 
stem und die Bibliotheken gegen Manipulationen von deren ei- 
genen "privaten" Daten, Programmcode und Stack durch ein lau- 
fendes Programm zu schutzen. Dies kann bei einem Ausfuhrungs- 
beispiel der Erfindung durch verschiedene Malinahmen erreicht 
werden: 

1. Segmentierte Adressierung: 

Der physikalische Adreliraum von 2^^ Bit wird uber maximal 256 
Daten- und 255 Programmsegmente zuganglich gemacht . Die Lange 
des physikalischen Adreliraums, der von einem Segment adres- 
siert werden kann, kann zwischen 4 Byte und 2^^ Byte .liegen. 
Ein Segment wird durch seine Lange und seine physikalische 
Anf angsadresse definiert. Die Adresse (Pointer) eines Spei- 
cherplatzes besteht dann aus 8 Bit, die die Adresse des Seg- 
ments darstellen und einem Offset aus 16 Bit. Dies bildet die 
direkte Adresse. 

2. Speicherverwaltungseinheit (Memory Management Unit = MMU) : 

Eine Speicherverwaltungseinheit (MMU) unterhalt eine Liste 
aller Segmente, die von den laufenden Programmen benotigt 
werden. Jedes dieser Segmente verfiigt iiber zusatzliche Attri- 
bute in der MMU, wie seine Eigenschaft als " Programmsegment " 
Oder "Datensegment " , Identif izierung des Programms, zu dem es 
gehort, und Vertrauensklasse . Verschiedene Programme, die zur 
gleichen Zeit laufen, werden durch unterschiedliche Programm- 
identif izierungen unterschieden . Programmzahler und Daten- 
adressen beziehen sich immer auf Segmenteintrage in der MMU 
mit der gleichen Programmidentif izierung . Weiterhin verweist 
das Segment des Programmzahlers auf einen Eintrag in der MMU 
mit der gleichen Segmentidentif ikation und dem Attribut "Pro- 
grammsegment". Andererseits konnen alle Datenadressen in der 
MMU-Eintragungsliste liber die gleiche Programmidentif izierung 
und das Attribut "Datensegment " gefunden werden. 
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3 . Vertrauensklassen: 

Wenn ein Hersteller ein Programm A schreibt, das auf ein an- 
5 deres Programm B eines anderen Herstellers zugreift, dann 

vertraut der erste Hersteller automatisch dem Code des zwei- 
ten Herstellers. Andernfalls wiirde er nicht auf dieses Pro- 
gramm zugegriffen haben. Andererseits wissen die Hersteller 
des Programms B nicht notwendigerweise irgend etwas iiber das 

10 Programm A. Daher mussen sie ihren Programmcode, den Stackin- 
halt und die Daten gegen schadliche Manipulationen durch Pro- 
gramm A schutzen. Dies muli insbesondere deshalb garantiert 
werden, well die Bibliothek B auch von anderen Anwendungspro- 
grammen benutzt werden kann, die sich auf eine korrekte Funk- 

15 tion der Bibliothek B verlassen. Erf indungsgemali wird dieser 
Schutz durch vier Vertrauensklassen (0 bis 3) die zusatzliche 
Attribute der Segmenteintrage in der MMU darstellen, unter- 
stutzt. Ein Programmabschnitt auf einer niedrigeren Vertrau- 
ensklasse genielit grofteres Vertrauen als ein anderer Pro- 

20 grammabschnitt mit einer hoheren Vertrauensklasse . So konnen 
Geratetreiber auf einem Segment mit der Vertrauensklasse 0 
liegen, das Kartenbetriebssystem auf Segmenten mit einer Ver- 
trauensklasse 1, Bibliotheken auf der Vertrauensklasse 2 und 
Anwendungen auf der Vertrauensklasse 3. Die Vertrauensklassen 
li^^25 spielen eine wichtige Rolle beim Aufstellen von Regeln flir 
Funktionsauf ruf e zwischen Segmenten (ferne Aufrufe) und dem 
Datenzugrif f . 

4 . Funktionseintrittstore : 

30 

Nur Funktionen, die von dem selben Hersteller einer Biblio- 
thek Oder Anwendung hergestellt worden sind, werden in ein 
Segment gepackt. Deshalb braucht ein Segment keine Schutzmafi- 
nahmen fur Funktionsauf ruf e innerhalb des Segments (nahe Auf- 
35 rufe) vorzusehen. Andererseits sind ferne Aufrufe potentiell 
gefahrlich. Einem Anwendungsprogramm darf es nicht erlaubt 
werden, einen Programmcodeabschnitt des Kartenbetriebssystems 
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an einer beliebigen Eintrittsadresse anzuspringen . Wenn dies 
namlich nicht verhindert wird, konnen unvorhersehbare Vorgan- 
ge ablaufen. Die derzeit bevorzugte Losung besteht darin, 
Adressen fiir ferne Aufrufe nicht als Funktionseintrittsadres- 

'5 sen, sondern als Funktionstore zu definieren. Ein Segment 

kann maximal 255 solcher Tore besitzen. Wenn ein Fernaufruf 
erfolgt, besteht die Toradresse aus einem Wort von zwei Byte 
Lange: Das hoherwertige Byte enthalt die Segmentidentif izie- 
rung und das niedrigere Byte das Tor der Funktion, das ange- 

10 sprungen werden soil. Der Fernaufruf liest das Wort automa- 

tisch mit dem unter 2. definierten Offset des entsprechenden 
^ Segments und interpretiert es als Funktionseintrittsadresse . 

Trotzdem ist die Ruckkehr von einem fernen Funktionsauf ruf 
moglicherweise gefahrlich, well die Riickkehradresse eine di- 

15 rekte Adresse auf dem Stapelspeicher (Stack) darstellt, die 
von der aufgerufenen Funktion verandert worden sein kann. 
Deshalb werden ublicherweise nur Fernaufrufe von hoheren Ver- 
trauensklassen auf niedrigere Vertrauensklassen erlaubt. Um- 
gekehrt sind nur Fernruckspriinge von niedrigeren Vertrauens- 

20 klasse auf hohere Vertrauensklassen zulassig. Eine Ausnahme 
sind die Fernaufrufe von den Vertrauensklassen 0 oder 1, die 
im folgenden diskutiert werden. 



Obwohl es sich bei den Funktionsauf ruf en ublicherweise urn 
1|©25 Funktionsauf ruf e innerhalb des Segments oder Funktionsauf ruf e 
auf derselben oder einer niedrigeren Vertrauensklasse handeln 
wird, ware es zu restriktiv, Fernaufrufe von hoheren auf 
niedrigere Vertrauensklassen vollstandig zu verbieten: Das 
Kartenbetriebssystem muft in der Lage sein, ein Anwendungspro- 

30 gramm zu starten. Auch das Protokoll zum Laden von Anwen- 

dungsprogrammen kann Ruckrufe benotigen, bei denen ein Funk- 
tionszeiger einer Funktion A auf einer hoheren Vertrauens- 
klasse an eine Funktion B auf einer niedrigeren Vertrauens- 
klasse iibergeben wird und Funktion B nachher Funktion A auf- 

35 ruft. Aufrufe von niedrigeren auf hohere Vertrauensklassen 
werden im folgenden kurz als "Ruckrufe" bezeichnet. Ebenso 
benotigt die virtuelle Javamaschine (JVM) solche Ruckrufe, um 
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ein Javakartchen zu starten. Grundsat zlich erlauben wir jeden 
fernen Aufruf, verbieten aber ferne Rucksprunge von einer ho- 
heren Vertrauensklasse in eine niedrigere Vertrauensklasse . 
Da auch Fernaufrufe von dem Kartenbetriebssystem auf ein An- 
"5 wendungsprograinin oder eine Bibliothek inharent unsicher sind, 
muB das Kartenbetriebssystem einen speziellen Mechanismus 
vorsehen, um sichere Ruckrufe auszufuhren. Dazu wird eine 
Kartenbetriebssystemfunktion INT-SAVE-CALL (FUNC, ARGl, ARG2 
•..) definiert, die aufgerufen werden muft, um einen Ruckruf 
10 durchzuf lihren. Die Aufgabe von SAVE-CALL, ist es, die Daten 

auf dem Stapelspeicher (Stack) einschliefilich des Rucksprung- 
vektors zu der Funktion, die SAVE-CALL aufgerufen hat, aber 
ausgenommen der Werte von FUNG, ARGl, ARG2 von Lese- und 

Schreibzugrif f en innerhalb der Funktion FUNG zu schutzen. 

15 

Grundsatzlich gibt es drei Losungen fiir SAVE-CALL: 

1, SAVE-CALL off net ein neues Stacksegment ; das Kartenbe- 
triebssystem verwaltet den Stackzugrif f ; 

20 

2. SAVE-CALL beschrankt den Schreib- und Lesezugriff auf das 
lauf ende Stack-Segment . 

Dabei gibt es wieder zwei Moglichkeiten, namlich: 

2.1. Das Kartenbetriebssystem verwaltet den Stackzugrif f . 

2.2. Die Fernaufruf- und Fernruckkehrinstruktionen verwalten 
den Stackzugrif f. 

30 

Fig. 2 zeigt die Ausfiihrung eines sicheren Rucksprungs auf 
eine Funktion FUNG () in Vertrauensklasse 3 von einem Aufru- 
fer in Vertrauensklasse 2. FUNG und seine Parameter werden 
als Parameter zu einer Betriebssystemf unktion SAVE-CALL iiber- 
35 geben. SAVE-CALL iibergibt FUNG und seine Argumente weiter zu 
einer Betriebssystemf unktion ACTUAL SAVE GALL in Vertrauens- 
klasse 3. Dieser Riicksprung ist nur zulassig, da sich SAVE- 
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CALL in Vertrauensklasse 1 befindet. ACTUAL SAVE CALL besitzt 
bereits einen geschutzten Stack, wenn es FUNC aufruft. Nach- 
dem FUNC zu ACTUAL SAVE CALL zuruckgekehrt ist, wird RETURN 
SAVE CALL auf dem Kartenbetriebssystem mit Vertrauensklasse 1 
5 aufgerufen. RETURN SAVE CALL gibt den Stack frei und ersetzt 
seinen Rucksprungvektor durch den Rucksprungvektor von SAVE 
CALL, der in einer Datei des Kartenbetriebssystems durch SAVE 
CALL selbst gespeichert worden ist. Sodann kehrt RETURN SAVE 
CALL zu der aufrufenden Funktion in der Bibliothek LIB zu- 
10 ruck. 

Erf indungsgemali gibt es fur die Realisierung der Funktion 
SAVE CALL zwei verschiedene Moglichkeiten: 

15 1. SAVE CALL eroffnet einen neuen Stack oder ein neues Stack- 
segment , 

Beim Aufruf von SAVE CALL ubernimmt diese Funktion den Stack 
mit folgenden Inhalten: 



20 



Operanden, Argumente, Name der Funktion FUNC, Rucksprunga- 
dresse zu dem aufrufenden Programm in LIB. 



Das Programm SAVE CALL fuhrt dann folgende Aktionen aus: Es 
wird ein neues Datensegment DS eroffnet, die Argumente und 
der Name der Funktion FUNC werden in das neue Datensegment 
kopiert, die derzeitige Rucksprungadresse fiir den fernen 
Riicksprung SP mit 24 Bit Lange wird in eine Datei des Karten- 
betriebssystems gespeichert, SP wird zu DS:LANGE gesetzt und 
30 die Funktion ACTUAL SAVE CALL wird aufgerufen. 

Die Funktion ACTUAL SAVE CALL ubernimmt daher folgenden 
Stackinhalt bevor die Funktion FUNC aufgerufen wird: 



35 



Argumente, Name der Funktion FUNC, Rucksprungadresse zu dem 
Programm SAVE CALL. 
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Das Programm ACTUAL SAVE CALL fuhrt nun folgende Aktionen 
durch: 

Hole den Rucksprungvektor vom Stack, lade die Adresse von 
"5 FUNC in den Akku, rufe die Funktion FUNC indirekt auf . 

Nachdem die Funktion FUNC ausgefuhrt worden ist, ist der 
Stack von ACTUAL SAVE CALL leer. Es wird sodann die Funktion 
RETURN SAVE CALL aufgerufen. Diese ladt das Register fur die 

10 Fernriicksprungadresse SP mit den ursprunglichen Werten, die 

in einer Kartenbetriebssystemdatei zwischengespeichert worden 
sind und loscht den zwischenzeitlich geschaffenen Stack oder 
das zwischenzeitlich geschaffene Stacksegment . Die Funktion 
RETURN SAVE CALL tibergibt sodann den Stack wieder in der an- 

15 fanglichen Belegung mit den Operanden, Argumenten, dem Namen 
der Funktion FUNC und dem Rucksprungvektor an das aufruf.ende 
Programm in LIB. Diese Rucksprungadresse wird nun in den Ak- 
kumulator geladen und damit springt der Programmablauf in das 
aufrufende Programm zuruck. Diese Vorgehensweise hat den Vor- 

20 teil, daii sie bei alien denkbaren Strukturen des Stacks ange- 
wendet werden kann. Es miissen jedoch die Argumente von FUNC 
kopiert werden und es muli eine Kartenbetriebssystemdatei zur 
Zwichenspeicherung der Rucksprungadresse angelegt werden. 

^if^25 2. Eine weitere erf indungsgemafie Losung fiir sichere Ruck- 

sprungauf ruf e fuhrt eine Schreib/Lesebarriere auf dem Stack 
ein, die den Rucksprungvektor zu dem aufrufenden Programm vor 
Veranderungen schutzt und ebenso den gesamten Stackinhalt des 
aufrufenden Programms von Schreib- und Lesezugrif f en schutzt. 

30 Das kann durch eine geeignete Verminderung der Lange des 
Stacksegments oder durch ein zusatzliches Register in der 
Speicherverwaltung (MMU) erreicht werden. Ein Problem, wel- 
ches dabei gelost werden muli, ist, daft die Argumente einer 
Funktion vor dem Rucksprungvektor liegen, wenn das konventio- 

35 nelle C-Stack-Layout benutzt wurde . Eine Losung dazu ergibt 

sich durch eine Neuordnung des C Stacks in einer solchen Wei- 
se, daft Platz fur den Rucksprungvektor reserviert werden muft. 
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bevor die Argumente auf den Stack gelegt werden. Dies flihrt 
zu einigem zusatzlichen Programmierauf wand fiir einen Funktio- 
saufruf im Vergleich mit dem ublichen Stack Layout. 

Im einzelnen erfolgt dieser weitere erf indungsgemafle Verfah- 
rensablauf wie folgt: 

Der Stack wird an SAVE CALL iibergeben. SAVE CALL setzt eine 
Lese- und Schreibsperre zwischen den Rucksprungvektor und die 
Parameter von SAVE CALL. Der Stack hat dann folgenden Aufbau: 

Operanden, Ruckkehrvektor zu dem aufrufenden Programm in LIB, 
Rlicksprung- Lese- und Schreibsperre, Argumente, Name der 
Funktion FUNC. 

Sodann wird das Programm ACTUAL SAVE CALL aufgerufen. Vom 
Programm ACTUAL SAVE CALL aus gesehen, besteht der Stackin- 
halt damit nur noch aus den Argumenten und dem Namen der 
Funktion FUNC, bevor die Funktion FUNC aufgerufen wird, da 
die Funktion ACTUAL SAVE CALL nicht uber die Lese- und 
Schreibsperre hinauslesen kann. 

Sodann wird zur Ausfuhrung der Funktion FUNC der Riicksprung- 
vektor vom Stack geholt, die Adresse der Funktion FUNC in den 
Akku geladen und die Funktion FUNC indirekt aufgerufen. 

Bei Ruckkehr aus der Funktion FUNC ist der Stack fiir die 
Funktion ACTUAL SAVE CALL leer. Die Funktion ACTUAL SAVE CALL 
ruft dann die Funktion RETURN SAVE CALL auf. Die Funktion 
RETURN SAVE CALL loscht Oder entfernt die Lese- und Schreib- 
sperre fiir den Stack, so dali der Stack fur die Funktion 
RETURN SAVE CALL wieder folgenden Inhalt hat: 

Operanden, Rucksprungvektor zu dem aufrufenden Programm in 
LIB, Rucksprungvektor zu ACTUAL SAVE CALL. Von dem Programm 
RETURN SAVE CALL wird dann der Rucksprungvektor zu dem Pro- 
gramm ACTUAL SAVE CALL vom Stack geholt und die Stackrahmen- 
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zeiger warden zuruckgesetzt . Das Programm ACTUAL SAVE CALL 
ubergibt die Kontrolle dann an das aufrufende Programm in 
LIB, 

'5 Hierbei ist zu beachten, dafi diese Vorgehensweise nur mit ei- 
ner besonderen Struktur des Stacks moglich ist. Diese Vorge- 
hensweise hat jedoch den Vorteil, dali die Argumente von FUNC 
nicht kopiert werden miissen, und keine zusatzlichen Dateien 
vom Betriebssystem angelegt werden miissen. 

10 

Weiter ist erf indungsgemafi noch die Losung denkbar, dafi eine 
bestimmte Anzahl von Argumenten in Register ubergeben werden, 
Ein sicherer Riicksprungauf ruf wtirde dann lediglich diese An- 
zahl von Argumenten als Maximum erlauben. Der Rucksprungvek- 
15 tor eines sicheren Riicksprungauf ruf s besteht dann aus dem 

Rucksprungvektor eines normalen Funktionsauf ruf s und zusatz- 
lich aus der Lange des alten Stacksegments . 

Weiterhin ware es erf indungsgemali auch moglich, den Riick- 
20 sprungvektor auf einem separaten Stack zwischenzuspeichern . 
Dann kann die Lese- und Schreibsperre einfach installiert 
werden, bevor das erste Funktionsargument auf den normalen 
Stack abgelegt wird. 

25 Weiterhin ist noch eine erf indungsgemalie Losung denkbar, bei 
der die gleiche Stackstruktur wie bei der vorstehenden Losung 
2 angewendet wird. Im Gegensatz zu den ersten beiden Losungen 
schiitzt jedoch nicht das Kartenbetriebssystem, sondern das 
aufrufende Programm selbst den Stack des aufrufenden Pro- 

30 gramms durch einen besonderen Befehl SEC CALL gegen Lese- und 
Schreibzugrif f . Bei der Ausfiihrung des Rucksprungbef ehls mufi 
dann gepriift werden, ob der Rucksprungvektor hinter der Lese- 
und Schreibbarriere liegt. Wenn dies der Fall ist, kann die 
alte Lese- und Schreibbarriere, die auf dem Stack hinter der 

35 aktuellen Barriere gespeichert worden ist, wieder hergestellt 
werden und der iibliche Rlicksprung ausgefiihrt werden. Andern- 
falls wird nur der iibliche Riicksprung ausgefiihrt. Im Hinblick 



GR 98 P 2895 



12 

auf die Struktur des Stacks entspricht diese Losung der vor- 
her beschriebenen Losung mit der besonderen Stackstruktur . 

Die Fig. 1 zeigt das einfachste Grundprinzip aller dieser er- 
'5 f indungsgemalien Losungen: 

Der Stackzugriff mufi bei einem Aufruf einer unsicheren Funk- 

tion auf deren Stackbereich durch Hardware beschrankt warden. 

Man erreicht dies durch Speichern des Stackf ramepointers der 

10 aufrufenden Funktion. Dabei ist ein Schutzmechanismus zu im- 

plementieren, so dali die aufgerufene Funktion den Wert des 

^ gespeicherten Stackf ramepointers nicht verandern kann. Aufier- 
w 

^ ' dem ist beim Schreiben auf den Stack sicherzustellen, dali der 
Stackpointer nicht den gultigen Stackbereich der aktuellen 
15 Funktion iiberschreitet . 

Der Schutzmechanismus kann automatisch aktiviert warden oden. 
von der aufrufenden Funktion direkt angestolien warden. 

20 Beim RETURN aus der unsicheren Funktion wird dabei durch eine. 
Hardwareimplementation der ursprungliche Zustand auf dem 
Stack wieder hergestellt. 

Entsprechend zeigt die linke Darstellung in Fig. 1 den Zu- 
■^jJn^S stand vor dem Funktionsauf ruf . Der Stackpointer SP zeigt auf 
die oberste belegte Speicherzelle im Stack, Unterhalb davon 
ist der Stack belegt, es darf aber auf den Stack zugegriffen 
werden. Der Stackf ramepointer SFP ist nicht belegt oder ent- 
halt einen Wert fiir eine Sperre aus einem fruheren Aufruf. 

30 

Die rechte Darstellung der Fig. 1 zeigt den Zustand nach dem 
Funktionsauf ruf . Der Stackpointer zeigt nun auf eine Spei- 
cherzelle weiter oben, die als letzte belegt ist. Nach dieser 
Oder diesen belegten Speicherzellen liegt als letztes die 
35 aufgerufene Funktion FN und ihre Argumente (ARG) . Der Frame- 
pointer zeigt auf ein Feld, in dem der alte Wert des Stack- 
f ramepointers zwischengespeichert ist (im Falle von mehrfa- 
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Chen geschutzten Funktionsauf rufen) , Oder das leer ist. Die 
Speicherzelle, auf die der Stackf ramepointer zeigt, ist auto- 
matisch fur den Zugriff gesperrt, da Zugriffe nur zulassig 
sind, wenn SP < SFP. Damit ist diese Speicherzelle und alle 
darunter folgenden auch gegen Manipulationen gesichert. 

Beim Funktionsauf ruf wird zunachst auf dem Stack ein Spei- 
cherbereich fur zu schiitzende Funktionsdaten reserviert 

(Rucksprungadresse, etc) . Anschlieliend werden die Funktions- 
argumente auf den Stack gelegt. Schlielilich wird beim Funkti- 
onsaufruf der im geschutzten Speicherbereich liegende SFP 

(mit dem Stackf ramepointer der aufrufenden Funktion der aktu- 
ellen Funktion) auf den zuvor reservierten Bereich des Stacks 
gelegt und der Stackf ramepointer der aktuellen Funktion in 
den geschutzten Bereich geschrieben (SFP) . Dies erfolgt ent- 
weder durch Betriebssystemauf ruf oder durch einen Hardwareme- 
chanismus . 

Bei Stackmanipulationen wird der Stackpointer stets mit dem 
abgespeicherten Wert SFP im geschutzten Bereich verglichen, 
um zu verhindern, daU der Stackbereich der aufrufenden Funk.— 
tion manipulierbar wird. 

Erf indungsgema/i handelt es sich also um eine Hardware unter- 
stiitzte Losung zur Absicherung des Stacks der aufrufenden 
Funktion gegen Uberschreiben . Der Rucksprung in die sichere 
Funktion und optional auch der Aufruf der unsicheren Funktion 
kann dabei ohne Interaktion mit dem Betriebsystem erfolgen. 
Dies bedeutet einen Geschwindigkeitsvorteil bei unsicheren 
Funktionsauf ruf en . 

Die Alternative ware, den Funktionsauf ruf nicht direkt auszu- 
fiihren, sondern den Funktionspointer und die Argumente der 
Funktion an das Betriebssystem zu iibergeben, das den bisheri- 
gen Stack absichert und anschlieliend die Funktion auf ruf e. 
Dies ist jedoch sehr kompliziert und rechenzeitauf wendig . 
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Durch die vorliegende Erfindung wird also die Implementation 
eines sicheren Callbacks in C und ftir die Java Virtual Machi- 
ne auf eine Chipkarte deutlich erleichtert. Unter anderem 
kann der Umweg uber das Betriebssystem, der meist ein grofies 
Handicap darstellt, erspart werden. 
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Patentansprtiche 

1. Verfahren zur Verhinderung von Stackmanipulationsangrif f en 
bei Funktionsauf ruf en, dadurch gekennzeich- 

"5 net, dafl der Stackzugriff bei einem Aufruf einer unsicheren 
Funktion durch Hardware auf den Stackbereich dieser unsiche- 
ren Funktion beschrankt wird. 

2. Verfahren nach Anspruch 1, dadurch gekenn- 
10 zeichnet, daJl zur Beschrankung des Stackzugriff s vor 

dem Aufruf der unsicheren Funktion eine Referenz auf den 
K^^, Stackframe der aufrufenden Funktion gespeichert wird. 

3. Verfahren nach Anspruch 2, dadurch geken n- 
15 zeichnet, dafi ein Mechanismus vorgesehen ist, durch 

den verhindert wird, dafi die aufgerufene Funktion auf den 
Wert der Referenz auf den Stackframe und alle davor auf dem 
Stack liegenden Daten zugreifen kann. 

20 4. Verfahren nach einem der Anspriiche 1, 2 oder 3, d a- 
durch gekennzeichnet, dafJ durch einen 
Schut zmechanismus sichergestellt wird, dafi der Stackpointer 
nicht den gultigen Stackbereich der aufgerufenen Funktion 
iiberschreitet . 

'#.2 5 

5. Verfahren nach einem der Anspruche 1 bis 4, dadurch 
gekennzeichnet, dafi bei dem Riicksprung aus der 
unsicheren Funktion der ursprungliche Zustand auf dem Stack 
wieder hergestellt wird. 

30 

6. Verfahren nach einem der Anspruche 1 bis 5, dadurch 
gekennzeichnet, dafi beim Funktionsauf ruf zu- 
nachst auf dem Stack ein Speicherbereich fur zu schutzende 
Funktionsdaten reserviert und optional dahinter die Funkti- 

35 onsargumente auf den Stack gelegt werden konnen und die im 

geschutzten Bereich liegende Referenz auf den Stackframe der 
aufrufenden Funktion auf den zuvor reservierten Bereich des 
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Stacks gelegt und die Referenz auf den Stackframe der aufge- 
rufenen Funktion in den geschiitzten Bereich geschrieben wird. 
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Zusammenf assung 

Verfahren zur Verbindung von Stackmanipulationsangrif f en bei 
Funktionsauf ruf en 

Hardwareunterstutztes Verfahren zur Verhinderung von Stackma- 
nipulationsangrif fen bei Funktionsauf ruf en, bei dem der 
Stackzugriff bei einem Aufruf einer unsicheren Funktion durch 
Hardware auf den Stackbereich dieser Funktion beschrankt 
wird. 



Fig. 1 
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